1. Technical Field of the Invention
This invention relates to mapping of an address space. More particularly, it relates to dual mapping of selected portions of a large address space as needed for aliasing into a smaller address space.
2. Background Art
Referring to FIG. 1, in the IBM Virtual Machine (z/VM) operating system, control program (CP) 50, working with 31-bit addressing capabilities in real storage 30, runs a virtual machine in virtual address space 32 of some size. This virtual machine operates on a guest page 40 in virtual storage 32 as though it were real space.
Generally a guest is a virtual machine, with one or more virtual address spaces which it thinks are in real storage. However, when a virtual machine is executing, CP 50 has instantiated, as is represented by line 41, guest storage, such as page 40, in real storage 30 at page location 42 below 2G line 36 (2G denotes two gigabytes, the limit of 31-bit addressing). Thus, CP 50 code written with 31 bit addressing, as it executes a virtual machine, works with page 42 which is guest page 40 made resident in real storage 30.
In the IBM z/Architecture, on which the IBM z/VM operating system runs, 64-bit registers and addresses are provided, giving much more real storage available to the hardware which CP 50 can use if code using 31-bit addresses is converted to use 64-bit addresses. Portions of the z/VM control program (designated CP64) have been upgraded to operate in 64-bit addressing mode and other legacy code (designated CP31) remains in 31-bit addressing mode. Stated otherwise, the IBM z/VM operating system needs to efficiently exploit a 64-bit address space, but much legacy code that remains from earlier versions of VM has already been written to function in a 31-bit address space. There is, consequently, a need in the art for a method and system which can refer to the much larger memory space without re-writing the legacy code.
Referring to FIG. 2, an initial solution used by the IBM Virtual Machine (z/VM) operating system is to have a small amount of code CP64 51 that is capable of addressing the whole 64-bit space, and using that code to copy any desired pages as needed. If code in CP31 50 needs to refer to a page 46 which has been instantiated (as is represented by line 43) in storage 30 frame 46 above 2G, that page 44 is copied (as is represented by line 47 from frame 46 to frame 48) to a location 48 below 2G, manipulated as desired, and later may be copied back (as is represented by line 47 from frame 48 to frame 46) to a location 46 above 2G. The drawback to this solution is that it is inefficient, therefore slow.
Another consequence of this initial solution is that any page pinned (e.g., for an I/O operation) must first be moved below the 2G line, even if the function requesting the pinning is 64-bit capable. This is necessary so that if the page is referenced from 31-bit code CP31 50 while it is still pinned, it will be accessible using a 31-bit address.
Therefore, this initial solution restricts the total amount of storage that can be simultaneously pinned to less than 2G, regardless of the total storage size, and may constrain the I/O bandwidth of the system. Similarly, under the initial solution, any fixed storage (storage which is declared not pageable for performance purposes) is limited to residing below the 2G line, so that 31-bit code can reference the fixed storage when needed. Thus, the aggregate fixed storage for all users is limited to 2G.